Create release.yml#100
Conversation
| tag="${{ inputs.project }}/${{ steps.version.outputs.version }}" | ||
|
|
||
| sudo apt-get update | ||
| sudo apt-get install build-essential libudev-dev qt6-base-dev qt6-base-dev-tools qt6-svg-dev |
There was a problem hiding this comment.
can be optimised further by checking project and skipping installng these.
| --title "Release $tag" \ | ||
| --notes "Release $tag" \ | ||
| --latest \ | ||
| bin/Packages/*tar* |
There was a problem hiding this comment.
Changelog.md and Changelog.fr.md can be modified here as well, let me know if that is something we wish to automate.
| bash src/${{ inputs.project }}/dist/source/source.sh | ||
|
|
||
| mv bin/Packages/*tar.gz bin/Packages/${{ inputs.project }}-${{ steps.version.outputs.version }}.tar.gz | ||
| mv bin/Packages/*tar.xz bin/Packages/${{ inputs.project }}-${{ steps.version.outputs.version }}.tar.xz |
There was a problem hiding this comment.
Do we need binary builds in the release assets? If we do, then I can setup a matrix build for aarch64 and x86_64 builds of linux.
|
|
||
| gh release create $tag \ | ||
| --title "Release $tag" \ | ||
| --notes "Release $tag" \ |
There was a problem hiding this comment.
Release notes can be autogenerated usually but its a monorepo, idk how one would go about doing that. One naive way I can think of is using the output from git log src/<project>.
|
Felix has its own code to read the git repository (in src/felix/git.cc). It uses the target name (or the VersionTag info specified for the target in FelixBuild.ini, if any), to find a signed tag (basic tags are ignored) that looks like If the tag is on the HEAD, that's it and the version string is the part after the slash. If not, if adds a dev suffix, and the version string ends up looking like I usually put the signed tag on a commit with the message "Bump Goupile to ", which contains the ChangeLog changes. I tend to use |
|
If felix finds a FelixVersions.ini file at the root, it loads it to get the version strings instead of using git tags. That's how source packages (without any git stuff) can end up with a version string: the version info is written to FelixVersions.ini. |
|
Thanks :) So the tag should already exist when the workflow is triggered. For Goupile 3.12 it will be goupile/3.12. I create this tag myself, as noted above, because that's how felix makes the version string basically. No need to create it. And let's keep the manual trigger; I don't like stuff that runs automatically somehow/somewhere when a commit happens. |
|
As far as binary builds are concerned, that would be good yes. Right now the dist/linux scripts can create:
Guess all the CI/CD stuff can just "start" them (they require podman and not docker). Same thing: manual trigger only. |
|
Will I have to use the gh client to trigger stuff, or will there be an easy-to-use API or a button I can click on the website? |
Signed-off-by: phanirithvij <phanirithvij2000@gmail.com>
gh cli is optional, but very useful for working with github, github actions etc. You can run workflow_dispatch (manually triggered) actions in the website. eg, screenshot Also github APIs are well documented and gh cli is open source, https://github.com/cli/cli MIT license.
I will create a shell script and a github action for publising release assets to a tagged release, say So you manually add changelogs, bump and push tag, then use |
Koromix
force-pushed
the
master
branch
3 times, most recently
from
1f5272f to
b2e5f3e
Compare
2 participants
closes #93
In my fork I got a basic github actions workflow to create tags and releases working.
It only supports a
workflow_dispatchevent i.e. manual workflow trigger from the actions tab. (can also use the gh cli like below)Note
A repository secret needs to be added in the repo settings, named GH_TOKEN with permission to push tags. Before the workflow can run.
There is another way of doing it, like detecting when a tag has been pushed and build release assets, but I thought this approach was better, as it fails to create a new tag if the build fails. Also it removes the friction and does automatic semver bump.
Please let me know for all the PRs I open what's lacking, and I can address them.
I am sure you are busy, but any reply at all would help me decide how to proceed.